1. Field of the Invention
The application relates to a method utilized in a wireless communication system and communication device thereof, and more particularly, to a method of handling proximity service (ProSe) in the wireless communication system.
2. Description of the Prior Art
A long-term evolution (LTE) system supporting the 3GPP Rel-8 standard and/or the 3GPP Rel-9 standard are developed by the 3rd Generation Partnership Project (3GPP) as a successor of a universal mobile telecommunication system (UMTS) for further enhancing performance of the UMTS to satisfy increasing needs of users. The LTE system includes a new radio interface and a new radio network architecture that provides high data rate, low latency, packet optimization, and improved system capacity and coverage. In the LTE system, a radio access network known as an evolved universal terrestrial radio access network (E-UTRAN) includes multiple evolved Node-Bs (eNEs) for communicating with multiple user equipments (UEs), and communicating with a core network including a mobility management entity (MME), a serving gateway, etc., for Non-Access Stratum (NAS) control.
An LTE-advanced (LTE-A) system, as its name implies, is an evolution of the LTE system. The LTE-A system targets faster switching between power states, improves performance at the coverage edge of an eNB, and includes advanced techniques, such as carrier aggregation (CA), coordinated multipoint transmission/reception (CoMP), uplink (UL) multiple-input multiple-output (MIMO), etc. For a UE and an eNB to communicate with each other in the LTE-A system, the UE and the eNB must support standards developed for the LTE-A system, such as the 3GPP Rel-10 standard or later versions.
Conventionally, when two mobile devices (i.e. UE 102 and UE 104) in close proximity communicate with each other, a data path (user plane) thereof goes via the operator network. The typical data path for this type of communication is shown in FIG. 1, where base stations (i.e. eNB 102 and eNB 104) and/or at least one gateway 1000 (GWs) are involved for communication between UEs 102 and 104. If the UEs 102 and 104 are in proximity of each other, they may be able to use a local or direct path to perform proximity service (ProSe) Communication. For example, in the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) spectrum, the operator may move the data path (user plane) off the access and core networks onto direct links between the UEs 202 and 204. This direct data path is shown in FIG. 2 between the UEs 202 and 204. Additionally, another example is provided when the data path is locally routed via the eNB 3002, and the locally-routed data path is shown in FIG. 3 for illustrating the communication between the UEs 302 and 304.
For the ProSe Communication scenarios depicted in FIG. 2 and FIG. 3, several control path scenarios may be applied. The following paragraphs and figures provide examples of potential control paths for different situations, understanding that other groups are responsible for defining the specific control paths associated with ProSe. When the UEs 402 and 404 involved in the ProSe Communication are served by the same eNB and the network coverage is available, the system 40 may decide to perform ProSe Communication using control information exchanged between the UEs 402 and 404, the eNB 4002 and the Evolved Packet Core (EPC) 4000, such as processing session management, authorization and security, as shown by the solid arrows in FIG. 4. For charging, signalling modifications should be minimized with respect to the existing architecture. The UEs 402 and 404 may in addition exchange direct signalling to support the ProSe Communication path as shown by the dashed arrow in FIG. 4.
When the UEs involved in the ProSe Communication are served by different eNBs 5002 and 5004 (e.g., border cell, macro/micro cell) and network coverage is available, the system 50 may decide to perform ProSe Communication using control information exchanged between the UEs 502 and 504, the eNBs 5002 and 5004 and the EPC 5000, such as processing session management, authorization, security, as shown by the solid arrows in FIG. 5. In this configuration, the eNBs 5002 and 5004 may coordinate with each other through the EPC 5000 or communicate directly for radio resource management as shown by the dashed arrow in FIG. 5. For charging, signalling modifications should be minimized with respect to the existing architecture. The UEs 502 and 504 may in addition exchange direct signalling to support the ProSe Communication path as shown by the dashed arrow in FIG. 5.
If network coverage is available to a subset of the UEs 600 and 604, one or more Public Safety UEs may relay the radio resource management control information for other UEs 600 and 604 that do not have network coverage. In comparison, if network coverage is not available, the control path may be directly between Public Safety UEs 600 and 604, as shown with the solid line in FIG. 6. In this configuration, the Public Safety UEs 600 and 604 may rely on pre-configured radio resources to establish and maintain the ProSe Communication. Alternatively, a Public Safety Radio Resource Management Function, which may reside in a Public Safety UE, may manage the allocation of radio resources for Public Safety ProSe Communication as shown with the dashed lines in FIG. 6.
Please refer to FIG. 7, which illustrates a schematic diagram of a conventional location reporting procedure. As shown in FIG. 7, the location reporting procedure is used by an MME to request the eNB to report where the UE is currently located when the target UE is in ECM-CONNECTED state. The need for the eNB to continue reporting ceases when the UE transitions to ECM-IDLE. This procedure may be used for services that require accurate cell identification (e.g. for emergency services, lawful intercept, charging).
In detail, the location reporting procedure includes three steps shown in FIG. 7. In the first step, the MME sends a Location Reporting Control message to the eNB. The Location Reporting Control message shall identify the UE for which reports are requested, the requested location information and may contain information such as reporting type. Requested location information is TAI+EGCI (i.e. Tracking Area Identity+Evolved Global Cell Identity). Reporting type indicates whether the message is intended to trigger a single stand-alone report about the current Cell ID serving the UE or start the eNB to report whenever the UE changes cell. In the second step, the eNB sends a Location Report message informing the MME about the location of the UE which shall include the requested location information. In the third step, the MME can send a Cancel Location Reporting message to inform the eNB that it should terminate location reporting for a given UE. This message is needed only when the reporting was requested for a reporting period.
Moreover, there is a demonstration of the conventional location change reporting procedure. The Packet Data Network Gateway (PGW) may request for each Packet Data Network (PDN) connection independently by using the “MS Info Change ReportingAction” parameter whether the MME should report changes of ECGI/TAI and/or by using “CSG Information Reporting Action” parameter whether the MME should report changes of user CSG information to the PGW. The PGW may also request the MME to stop reporting ECGI/TAI and/or user CSG information changes. The MME should obey the last explicit instruction received from the PGW or source MME/S4-SGSN.
If ECGI/TAI and/or user CSG information are permitted to be sent to the PGW operator according to MME operator's policy, the MME should include an indication for the support of reporting changes in ECGI/TAI and/or user CSG information when signalling to the PGW during both mobility management and session management procedures. If the level of support changes during a mobility management procedure then the MME shall indicate the current level of support to the S-GW and shall in addition provide ECGI/TAI even if the PGW has not requested this information. This could for example happen during MME change when the level of support indicated by the old MME is not the same as in the new MME. The inclusion of ECGI/TAI may trigger a Modify Bearer Request message from S-GW to the PGW and therefore this may make sure that the new level of support reaches the PGW. Besides, The PGW shall not request the MME to report ECGI/TAI and/or user CSG information changes if it has not received the indication for support from the MME.
Please refer to FIG. 8, which illustrates a schematic diagram of a conventional notification for the ECGI and/or user CSG information changes. As shown in FIG. 8, step 1a indicates that if the ECGI of the UE changes, the MME receives the ECGI information Update from the eNB, and step 1b indicates that the MME detects that the user CSG information has changed by comparing with the MME stored user CSG information. Noticeably, step la and step lb are independent, such that it is also possible that these two changes are triggered at same time. Step 2 indicates that if the MME has been requested to report the ECGI and/or user CSG information changes to the PGW for the UE, the MME should send the Change Notification message to the SGW indicating the new ECGI and/or user CSG information. The MME stores the notified user CSG information. Step 3 indicates that The SGW forwards the Change Notification message to the PGW. If dynamic PCC is deployed, and ECGI changes need to be conveyed to the PCRF, then the PGW should send this information to the PCRF. Step 4 indicates that the PGW sends the Change Notification Ack to the SGW, and step 5 indicates that the SGW forwards the Change Notification Ack to the MME.
Furthermore, there is a demonstration of the external identifier. A subscription used for MTC has one IMSI and may have one or several External Identifier (s) that are stored in the HSS. External Identifier should be globally unique, and includes the Domain Identifier and the Local Identifier. The Domain Identifier identifies a domain that is under the control of a Mobile Network Operator (MNO), and is used to identify where services provided by the operator network can be accessed (e.g. MTC-IWF provided services). An operator may use different domain identifiers to provide access to different services. Additionally, the Local Identifier is used to derive or obtain the IMSI, should be unique within the applicable domain, and is managed by the Mobile Network Operator.
Although the conventional communication has provides the ProSe communication in an Evolved Packet System (EPS) comprising the mobile device (UE), the base station (eNB) and network entities supporting the ProSe feature, it is not clear how the EPS determines the feasibility of the ProSe communication for the UE. Also, when initial deployment of the ProSe in the EPS, it is possible that the some network entities in the EPS do not support a ProSe feature, i .e. homogeneously support of the ProSe feature in the EPS is not feasible, such that it is unknown how the network handles such scenario. What's more, it is not clear how a ProSe-enabled UE discovers an interested UE/group in the proximity and how the UE initiates the ProSe communication with another UE.
Therefore, it is important to provide another method of handling device to device communication, so as to provide another proximity service in a wireless communication system.